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As we push toward new and diverse space transportation capabilities, reduction in operations cost 
becomes increasingly important. Achieving affordable and safe human spaceflight capabilities will be 
the mark of success for new programs and new providers. The ability to perceive the operational 
implications of design decisions is crucial in developing safe yet cost competitive space transportation 
systems. Any human spaceflight program — government or commercial — must make countless decisions 
either to implement spacecraft system capabilities or adopt operational constraints or workarounds to 
account for the lack of such spacecraft capabilities. These decisions can benefit from the collective 
experience that NASA has accumulated in building and operating crewed spacecraft over the last five 
decades. 


This paper reviews NASA’s history in developing and operating human rated spacecraft, reviewing the 
key aspects of spacecraft design and their resultant impacts on operations phase complexity and cost. 
Specific examples from current and past programs — including the Space Shuttle and International Space 
Station— are provided to illustrate design traits that either increase or increase cost and complexity 
associated with spacecraft operations. These examples address factors such as overall design 
performance margins, levels of redundancy, degree of automated failure response, type and quantity of 
command and telemetry interfaces, and the definition of reference scenarios for analysis and test. 

Each example— from early program requirements, design implementation and resulting real-time 
operations experience — to tell the end-to-end “story” 


Based on these experiences, specific techniques are recommended to enable earlier and more effective 
assessment of operations concerns during the design process. A formal method for the assessment of 
spacecraft operability is defined and results of such operability assessments for recent spacecraft 
designs are provided. Recent experience in applying these techniques to Orion spacecraft development 
is reviewed to highlight the direct benefits of early operational assessment and collaborative 
development efforts. 
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As we push towards new and diverse space transportation capabilities, reduction in operations cost 
becomes increasingly important. Achieving affordable and safe human spaceflight capabilities will 
be the mark of success for new programs and new providers. The ability to perceive the 
operational implications of design decisions is crucial in developing safe yet cost competitive space 
transportation systems. Any human spaceflight program — government or commercial — must 
make countless decisions either to implement spacecraft system capabilities or adopt operational 
constraints or workarounds to account for the lack of such spacecraft capabilities. These decisions 
can benefit from the collective experience that NASA has accumulated in building and operating 
crewed spacecraft over the last five decades. This paper reviews NASA’s history in developing and 
operating human rated spacecraft, reviewing the key aspects of spacecraft design and their 
resultant impacts on operations phase complexity and cost. Specific examples from current and 
past programs — including the Space Shuttle and International Space Station— are provided to 
illustrate design traits that either increase or decrease cost and complexity associated with 
spacecraft operations. | These examples address factors such as overall design performance 
margins, levels of redundancy, degree of automation, type and quantity of command and telemetry 
interfaces, and the definition of reference scenarios for analysis and test. Based on these 
experiences, specific techniques are recommended to enable earlier and more effective assessments 
of operations concerns during the design process. Recent experience in applying these techniques 
to Orion spacecraft development is reviewed to highlight the direct benefits of early operational 
assessment and collaborative development efforts. This paper serves as a companion piece to the 
earlier published “Designing a Better Spacecraft: Assessing Flight Operability of Human Rated 
Spacecraft,” presented at the AIAA SpaceOps 2010 conference. Where the previous paper 
described a method for formal flight operability assessment during spacecraft development, this 
paper provides expanded examples of design practices and their impacts on operability. 


I. Introduction 


HE design of a human rated spacecraft is a complex and costly process requiring the integrated assessment of 

many individual criteria. Historically, it has been difficult to include in that integrated assessment the design’s 
full impact on the flight operations community. The unique “operability” requirements have not been well 
understood, nor has there been a well-defined set of criteria for assessing operability. Spacecraft today are far more 
complex than their predecessors, implementing far larger requirements sets using advanced technologies and 
sophisticated software while providing more onboard capabilities, more telemetry and more operator command 
capabilities. Just as important as these architectural differences are the differences in missions. Today, there is a 
much higher expectation with regards to safety, mission success, mission frequency, and affordability. These all 
present challenges to the program and flight operations communities. 

Spacecraft requirements definition, design, manufacture and test is a complex and demanding series of processes 
that must take into account a vast array of considerations and constraints including safety standards, schedule and 
cost constraints, and even political factors. With all of these competing factors influencing the design process, it is 
at best challenging to develop a spacecraft that enables low operations phase cost. However, an awareness of the 
factors that impact flight operations costs, and a method to directly measure these impacts, can arm future spacecraft 
development program management and engineering organizations to better address these costs during the earlier 
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phases of a human spaceflight program. This same understanding can also benefit non-government organizations as 
they make their first attempts to build and fly human-rated spacecraft. 


II. The Flight Operations Job 


To understand the impacts of a spacecraft design on flight operations cost, it is necessary to first understand the 
basic function of flight operations. Apollo 11 flight director and former director of NASA JSC's Mission Operations 
Directorate Eugene Kranz defined the flight operations infrastructure as a system designed to “maximize mission 
success, to minimize risks to the [vehicle] and the crew, to decrease operating costs, and to achieve an effective 
balance in the application of all operational resources.’” The flight operations community picks up where the 
development community leaves off, turning generic design reference missions and system test cases into plans, 
procedures, and operating guidelines to meet the requirements and constraints of real missions. The successes and 
shortcomings experienced in the development, integration and test phases directly impact the form that flight 
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program’s lifecycle. 


This systems engineering and integration role continues — and even expands — as the program enters its 
operations phase and the details of specific missions must be defined. Mission specific planning entails the analysis 
not only of the generic operations constraints defined during spacecraft development, but also the unique constraints 
imposed by the mission requirements and payloads. Typical challenges include complex power configurations and 
reconfigurations to meet power budget limits, reconfiguration of attitude control system settings to conserve 
propellant, and flight attitude restrictions imposed not only due to communications line-of-sight constraints, but also 
concerns over overheating or freezing of individual spacecraft components. At the same time, flight plans must 
provide for efficient use of crew time and communications bandwidth to support mission goals such as science, 
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engineering tests, and in-space assembly operations. The flight plan, and associated mission-specific flight rules, 
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A sample page from a Space Shuttle detailed rt 
mission timeline is given in Figure 3. 


A. The Role of the Flight Crew 

From the beginning of the US human ] 
spaceflight program, the most critical part of 
the flight crew’s job has been that of system 
management. Certainly, piloting skills are 
crucial for the astronaut, but the human's 
unique ability to assess and respond to unique 
circumstances make the entire spacecraft more | 
robust. The primary role of the project 
Mercury astronaut was that of monitoring 
spacecraft system operation and intervening 
when necessary.” Onboard automation had successfully managed simple missions, but the onboard “sequencer” 
hardware proved to be a troublesome system to integrate and test.’ The human flight crew was the ultimate backup 
and could take control of the vehicle in most phases of flight using a separate manual control system implemented 
alongside the automated systems. 

The importance of this role was illustrated in numerous significant events during Mercury flight operations. On 
the United States’ first human orbital mission, MA-6, John Glenn took manual control of spacecraft attitude when 
malfunctions in the automated attitude control system threatened to deplete the vehicle’s propellant. On the later 
MA-8 mission, Wally Schirra overrode environmental control system functions to lower escalating suit 
temperatures, thereby avoiding an early mission termination.* Such flight experience demonstrated that this monitor 
and override role was a demanding, time consuming task for the crewmember. 

As NASA gained experience and confidence in the abilities of humans to work effectively in space, it was 
recognized that further implementing human-in-the-loop solutions resulted in higher reliability. The Gemini 
spacecraft design capitalized on these findings, reducing the level of automation and providing better display and 
control capabilities to enhance the human’s ability to operate the vehicle. 
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B. The Role of Mission Control 

The Mission Control Center (MCC) provides a necessary capability both during normal operations and in the 
event of the unexpected. Real-time MCC support provides more insight, more experience, and more resource to 
augment the crew throughout mission execution. The MCC provides analysis results, generates plans and 
procedures to optimize the crew's productivity, performing spacecraft system monitoring and control, and 
coordinating with external engineering expertise as required to address problems encountered in flight. Overall, 
MCC provides a both a strategic planning capability and an additional systems management resource that make the 
crew more efficient and maximize the crew’s opportunity for success. 

During nominal operations, these services reduce the crew workload associated with managing onboard systems 
and preparing for upcoming events. International Space Station (ISS) flight controllers have the full capability to 
operate spacecraft systems just as can the onboard crew, with the exception of strictly manual tasks such as opening 
and closing hatches. By exercising these capabilities from the ground, MCC support enables the crew to concentrate 
on supporting the core mission of the ISS — execution of experiments and tests in the unique laboratory environment 
that ISS provides. Without MCC support, the onboard crew would be required to spend more time managing the 
spacecraft core systems and less time in meeting the scientific objectives of the ISS program. 

During complex operations such as vehicle rendezvous and docking or response to onboard system failures, 
MCC provides more “eyes” and “hands.” Again, MCC can execute procedures from the ground, offloading the 
crew during intense operations periods and allowing crewmembers to focus on physical tasks that only they can 
perform. The spacecraft’s extensive telemetry and remote command capabilities, matched with extensive system 
specialist training give MCC flight controller the most detailed insight and skill in responding to system failures. 


3 
American Institute of Aeronautics and Astronautics 


C. Evolution of Flight Operations Capabilities 

Growth and change in mission scope accounts for much of the cost for the flight operations community. Initial 
plans for the Space Shuttle program included only a very limited set of Extravehicular Activity (EVA) operations 
requirements, focused on contingency operations such as manual payload bay door closure following a failure 
preventing nominal, automated door closure. However, the program expanded Space Shuttle EVA capabilities to 
become a part of normal operations for many flights. This change alone accounted for a significant increase in the 
cost and complexity of flight operations.” 

Any new program experiences a steep 70 
learning curve as it first enters the 
operations phase. Despite the best test, 
integrations, and flight preparation efforts, 50 
early operations uncover previously 
unknown component operating 
characteristic, failure modes, and system 39 
interdependencies that can change the 
nature of spacecraft operations. Figure 4 29 
illustrates the trend in in-flight anomalies 
experienced throughout the Space Shuttle 
program. The first 15 years of the 0 
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the 30 year program that the rate of in- 
flight anomalies reached a relatively low Figure 4. History of Space Shuttle anomalies per flight. 
and consistent level. 

At the same time, the process of learning through operations enables greater efficiency. Over the latter two 
thirds of the Space Shuttle Program — from 1991 to 2011 — the size of the space shuttle flight operations staff shrank 
by over 50% while the number of mission objectives and the complexity of spacecraft systems grew. As the 
organization learned the true limits and capabilities of the spacecraft, pre-mission planning capabilities improved 
and became more efficient. The smaller staff proved capable of handling an amazing array of mission scenarios, in 
many ways far beyond the scope of those envisioned at the beginning of the program. Similar trends continue today 
as International Space Station flight control and instructor positions are combined to achieve a significantly smaller 
overall workforce. 

Human Spaceflight operations will continue to evolve both as the commercial market for human spaceflight to 
Low Earth Orbit grows and our human exploration efforts reach deeper into the solar system where communications 
between the spacecraft and Earth are limited and delayed. 


II. Flight Operability 


The measure of a system's flight operability is the measure of the degree to which that system enables a balance 
of maximum mission success, minimal risk, and minimum operating cost. Traditionally, the human flight operations 
community has been held to the highest standards of safety and mission success, leaving operating cost as the most 
variable of these factors. 

Any measure of flight operability must encompass the impact on cost, responsiveness and risk incurred in safely 
executing operations with a spacecraft as designed and manufactured. Cost is driven by both the developmental 
investments required to build the operations infrastructure (facilities, operations techniques and products, and trained 
personnel prepared to execute operations) and by the recurring cost of maintaining that infrastructure and by the 
expense of executing mission planning, training and operations over the entire operations phase. Responsiveness 
reflects the time required to plan and execute a given operation. Excessive time requirements reduce the availability 
and responsiveness of operations. Risk is the likelihood of success or failure of the operation. Additional 
consideration of risk must be given in the case that a failure endangers crew health, vehicle integrity or mission 
success. “Operations Integration” is the practice of weighing and balancing these factors. 
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Flight operability is not only a function of the vehicle design, but also the mission requirements that the system 
must support. Therefore, a given system design may have different operability “scores” for different types of 
mission scenarios and operations. Consider a vehicle designed solely to achieve and maintain Low Earth Orbit may 
exhibit significant propellant margin in performing that mission. That same vehicle design may provide little or no 
margin if the mission is changed to achieve and maintain a lunar orbit. Therefore, a complete measurement of flight 
operability begins with the definition of the system or vehicle under study and the operational scenario in which 
operability is to be 
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Figure 5. Spacecraft flight operability assessment scale format 


II. The Elements of Flight Operability 


A review of the many individual recommendations of the human spaceflight operations community indicates six 
major operability themes — simplicity, margin, robustness, flexibility, situation awareness and control. These themes 
are discussed below. Note that, if not properly balanced, these operability themes can pose conflict. Features that 
make a system more robust may also make the system more complex. The judgment of subject matter experts must 
be applied to strike balance in these cases. 

Fundamentally, human flight operations support capability should be tasked primarily with dealing with the 
tough decisions and the less predictable scenarios. Expending significant human effort in executing the predictable, 
the mundane, and the formulaic can be a waste of resources and even a risk. While humans can conceive of and 
enact novel solutions to unexpected challenges — far more than any automated system — humans are less appropriate 
in performing repetitive tasks in a uniform manner. To support this decision making process, spacecraft systems 
should provide the flexibility, robustness, and margin necessary. This includes a well documented, analyzed and 
verified understanding of the real limits of the spacecraft both in the nominal configuration and through a reasonable 
range of off- nominal conditions such as unusual attitudes, contingency power downs, and post-failure operations. 
Armed with this knowledge and understanding, the human operator requires appropriate situation awareness and 
control capability to understand the context of his or her decisions and to efficiently take action on those decisions. 


A. Simplicity 

Simplicity — often referred to with its inverse, complexity — is the collective measure not only of the functions, 
interfaces and dependencies inherent in the system architecture, but also of the observations, decisions and actions 
required of the human operator. The number and ease of operation of functions and interfaces in the operational 
environment drive the number and cost of analyses, tools, procedures, plans, constraints and training required. 
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Simple systems that have few dependencies and few possible system configurations generally require fewer 
procedures, less training, and less effort to monitor and control. 

Simplicity cannot be measured in the design of the spacecraft and its subsystems alone. One must also consider 
the challenges of the mission and the spacecraft’s ability to meet those challenges. Consider the simplest version of 
a car — a pedal powered four wheeled vehicle with a minimum of moving parts and very simple operating and 
maintenance instructions. Though easy to operate in its intended environment — a driveway or a sidewalk, that same 
vehicle becomes extremely difficult and unsafe (as well as illegal) to operate on a city street or across long 
distances. Ultimately, a spacecraft design and operating characteristics must be matched to the mission. 


1. Example — Apollo LiOH canister incompatibility 

Perhaps the most well known example of complexity in the history of the US human spaceflight program is that 
of the Carbon Dioxide (CO2) scrubbing equipment on the Apollo Command Module and Lunar Module. The two 
spacecraft, though joined together for much of their mission and sharing both a common crew and a common 
atmosphere, used two separate and incompatible Lithium Hydroxide (LiOH) cartridges to remove CO2 from the 
cabin atmosphere. One of the more celebrated successes of the Apollo 13 contingency crew return was the real-time 
effort of the operations team to develop a means to use a Command Module LiOH cartridge in the Lunar Module 
system built for a cartridge of a completely different shape. The use of two entirely different components to perform 
the same function is a clear example of unnecessary complexity in the overall spacecraft architecture. 


2. Example — ISS Antenna Management 

The ISS boasts an impressive communications system, including redundant S-Band communication for voice, data 
and core commanding and a Ku-Band system for video, audio and payload data. Operation of this system requires 
the management of the antennae and their relationship to Tracking and Data Relay Satellites, ensuring that ISS stay 
in contact with satellites that are within line-of-sight. This function was intended to be managed by software 
onboard the spacecraft, but an effective onboard management function was not available in the flight software for 
the first decade of ISS operations. Instead, MCC actively managed the onboard system, uplinking commands every 
day to direct the communication system to change its selected target satellite as ISS traveled through its orbit. The 
calculation, generation, and management of the associated commands represented a significant workload for MCC, 
as well as an increased risk of temporary loss of communication in the event of a human error. Operationally, this 
ground-in-the-loop control process was overly complex. Today, the flight software capability to manage this system 
has been implemented, reducing the reliance on and workload of the MCC communications and tracking officer. 


3. Example — Space Station Evolution from On-Orbit Component Assembly to Pre-Integrated Truss 

Early designs for Space Station Freedom called for the main truss of the vehicle to be a built by hand — a lengthy 
and complicated process requiring astronauts to assemble a square truss from individual poles and connector nodes, 
adding wire harnesses and external avionics components as the truss grew out of the Space Shuttle payload bay. 
This difficult process involved as many as 7 separate robotic systems working in tandem with the astronauts and 
ultimately required the execution of final integrated test and verification of the spacecraft only after it was 
assembled on orbit. The complexity and risk of this approach became clear as assembly planning and analysis 
studies pointed to problems throughout the process. In the early 1990’s, a fundamental design and philosophy 
change was enacted, implementing a “Pre-Integrated Truss” or PIT to decrease the risk and increase the efficiency 
of on-orbit assembly tasks.’ This design matured as the Space Station Freedom Program evolved into the 
International Space Station Program, and was successfully implemented over the assembly phase of that program. 
Even with this fundamental simplification of the assembly sequence, ISS assembly proved to be a formidable 
engineering challenge. 


4. Recommendations 

To address operability concerns, hardware and software should be as simple as practical, minimizing the number 
of unique interfaces, algorithms, and functions that require separate operational techniques to monitor and control. 
Functions and interfaces should be common and consistent, requiring a reasonable number of tasks and 
methodologies on the part of the operator. Tasks themselves should be simple, allowing the operator to concentrate 
on decisions to be made rather than detailed operational sequences to be performed. There are reasonable limits on 
the operationally desirable level of simplicity. A system that is so simple that it does not provide the flexibility or 
robustness to perform in off-nominal scenarios is not operationally viable. Careful consideration of the other 
operability factors should be included in an assessment of the appropriate level of simplicity in a system. 
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B. Robustness 

Robustness describes the system's ability to cope with changing conditions resulting from both nominal and off- 
nominal operations. Flight operations planning and analysis costs are often driven by the need to “protect” the 
system or vehicle from certain conditions and events. The nature and degree of these “protection” measures is 
determined by the system's or vehicle's robustness. Note that provisions such as performance margin and 
consumables margin is assessed in a separate “margin” category. The “robustness” category addresses redundancy, 
fault tolerance, cross-strapping and similar system architecture traits. 


1. Example — Increased robustness in the Gemini Spacecraft Design 

During Project Mercury, it was found that the pairing of electrically-sensitive computing equipment with 
mechanical components such as pumps left critical avionics prone to electrical transients that could interfered with 
or even interrupt their operation. Subsequent spacecraft designs addressed this concern through isolation of critical 
equipment on separate “essential” electrical buses. Similar approaches were used in other Gemini systems, as 
evidenced by the provision of a separate set of life support, electrical, and propulsion systems dedicated to provide a 
safe emergency return to the Earth’s surface. The Space Shuttle architecture reflects this same philosophy not only 
in its electrical power distribution system, but also in its data bus architecture. Similarly, ISS provides isolation of 
critical system command and control functions from non-critical payload and video systems. This method of 
compartmentalization and channelization can reduce operational risk, as well as analysis required to ensure that 
nominal and off-nominal subsystem configurations are safe. 


2. Example — Thorough testing in the Apollo Program 

Successful execution of the Apollo Program is attributed in part to its thorough approach to testing. The limits of 
the hardware and integrated systems were well understood, allowing the program and the operations community to 
make well informed decisions as contingencies, both before and during flight, arose. 


3. Example — Space Shuttle Data Processing System (DPS) Redundancy 

The Space Shuttle ushered in an era of greatly expanded software capability in human spaceflight. General 
Purpose Computers (GPCs) provided overall command and control capabilities for the spacecraft, including closed 
loop control of the systems and flight path during dynamic flight. To protect against both hardware and software 
malfunctions during these critical operations, the DPS provided both a set of four redundant, synchronized GPCs 
and a separate fifth Backup Flight System (BFS) that used identical computer hardware but dissimilar flight 
software. The BFS was never used in flight, but the redundant set of primary GPCs provided a robust capability to 
continue flight after failures in individual computers. 


4. Recommendations for Achieving Appropriate Robustness 

To achieve operational robustness, flight systems should be designed to maintain fail operational capability (no 
loss of functionality after first failure); the design should ensure no single failure puts the mission in to a 
contingency. Systems should remain partially capable in off-nominal scenarios, allowing the continued use of 
remaining functionality without requiring significant operator action to recover that functionality. In many cases, 
cross-strapping - interconnections between components of two or more separate strings - are effective means for 
improving robustness in off-nominal scenarios. Redundant strings should be supported by separate data and power 
utility feeds to allow continued system availability after a single failure. 

No time-critical operator action should be required to prevent loss of mission, crew or vehicle. Time-critical 
operator actions are those that must be performed by a person within a limited time frame immediately following an 
event to ensure continued safe and effective mission execution. In general, the vehicle should automatically identify 
and reconfigure in response to failures that can impact mission success or crew/Vvehicle survival. Automated 
responses should result in predictable vehicle configurations that support crew and vehicle survival. 

The need for robustness is somewhat bound by the overall goals and mission scenarios that define the system and 
its operation. For a given spacecraft, a set of reference missions and configurations defines cases in which the 
vehicle is expected to either complete or abort the mission. Robustness should be provided to support mission 
execution within the expected bounds (including off-nominal scenarios) and to support mission abort or early 
termination once the defined criteria have been met. Robustness beyond that needed for these cases may not be 
warranted. 
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C. Margin 

Operational margin describes the amount of capability or consumable supplies available beyond that required to 
execute the mission. Operational margin provides assurance that the nominal mission may be safely executed and 
allows for continued operation in the event of unexpected conditions such as malfunction or mission scenario 
changes. 

There are three categories of operational margin: 


e Performance Margin - the ability of the system to provide greater capability than required for normal 
operation or in the event of any single failure. Measures of performance margin vary by vehicle 
subsystem. For example, performance margin for an electrical power system might be measured by 
power output capability while the measure for a communication system might be associated with the data 
bandwidth sizing. 

e Resource Margin - the amount of consumable commodities (propellant, atmospheric gases, stored energy) 
available beyond that required to support nominal flight operations. 

e Environmental Tolerance Margin - the system's ability to operate beyond the nominal operations 
environment for a given mission profile. 


Often, operational constraints and controls are required to ensure that adequate capability is available throughout 
a nominal mission and after an anomaly. These constraints and controls typically impact the ability to successfully 
complete all mission goals, as they limit the use of capabilities and resources even before an anomaly occurs. They 
also require the addition of more techniques, tools, products and training to the operations infrastructure. All of these 
additions result in increased life cycle cost. Margin is considered available for operational consideration only when 
formal analysis documentation of that margin is made available to the operations community. Lack of margin can 
have profound impacts on mission planning as well as real-time operations. More detailed pre-flight analysis must 
be performed to ensure that mission objectives may be met within the available resources, that the vehicle can 
perform required operations within its normal performance envelope, withstand potential anomalies, and that the 
flight environment does not exceed the vehicle's limits. Lack of margin not only impacts the mission operations 
organization, but it also drives significant program sustaining engineering costs to provide additional case-specific 
analyses that support the flight operations community as well as program strategic planning. 


Figure 6 provides a simple example 
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1. Example — Creating Power Resource Margin During Early ISS Operations 
During the early phases of ISS assembly, the US segment of the spacecraft had very limited redundancy in 
powering critical subsystems. With only 2 power channels available, the US power system was easily loaded to 
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capacity in supporting not only the vehicle core systems, but also early science operations. Each power channel 
could support a load of approximately 18 kW, but the failure of any one of the three batteries would cause an 
immediate overload — and shutdown — of one of the two power channels. To make matters worse, loss of power to 
the critical command, control and communications systems would leave the crew and ground unable to take action 
for several minutes as the data system reconfigured in response to multiple computer loses. With the risk of a major 
setback early in the program, program and operations management determined that the power budget for each 
channel would be limited to ensure that each power channel could continue to operate after that first potential 
battery failure. In effect, a 1/3 margin was imposed on all operations. As vehicle assembly continued, the US 
power system grew from its early 2 channel configuration to a full 8 channel system. 


2. Example — Environmental Tolerance Limits During ISS Assembly 

Early in ISS assembly operations, the STS-92 mission gave a clear example of environmental tolerance limits 
and their impact on operations complexity. STS-92 delivered the Z1 element — a large square truss segment 
containing key power, communications, thermal and attitude control system components to the fledgling ISS. Until 
crewmembers could attach data and electrical umbilicals to power the Z1 components and heaters associated with 
those components, flight attitudes exposing those components to sunlight were necessary to maintain temperatures 
above individual component freeze points. Unfortunately, these same sun-pointing attitudes placed too much 
sunlight on the Space Shuttle’s airlock water lines, risking overheating and damage to the airlock required to support 
the mission’s EVAs. Further complicating the mission planning process, the lack of power and data connections to 
those components prevented the crew and ground from monitoring these temperatures directly. Instead, pre-flight 
thermal predictions alone would provide the basis for the operators’ understanding of risk to ISS equipment. 
Thorough analyses of both Space Shuttle and ISS temperature profiles - analyses involving not just the flight 
operations community, but also the program office and spacecraft vendors to investigate secondary impacts to 
propellant usage, communications availability, and many other factors- were required to support the development of 
a flight attitude timeline that would meet all of the constraints placed on this mission. Ultimately, a carefully 
orchestrated series of attitude maneuvers were performed, flipping the mated Shuttle-ISS “stack” repeatedly 
throughout the EVA. The mission was successful, but at a cost of months of analysis employing a large community 
of engineers. 


3. Example — Performance Limits Impacting ISS Operations 

Changes in the Space Station assembly plan impacted the sequence in which vehicle elements would be 
delivered and the flight attitudes and environments that those elements to which those elements would be exposed. 
One of the many results was a significant increase in the rotation of solar arrays. Rotary joints intended to slowly 
pan back and forth over a period of weeks were now required to continuously rotate at 4 degrees per minute for 
years at atime. This far exceeded the performance requirements for the joints and, predictably, the joints began to 
exhibit the effects of wear in flight. Bearings developed increased resistance, occasionally exceeding their drive 
motor torque limit and “tripping” the joint control offline. The engineering and operations community worked 
together to develop a number of new operating techniques, procedures and modes both to reduce the frequency of 
rotation and to respond to the accumulation of torque resistance. These techniques were successful and allowed the 
continuation of ISS assembly to the point where such frequent and high rate rotation is not required. However, this 
serves aS an example of performance and performance margin that was not properly matched to the mission 
requirements. 


4, Recommendations for Achieving Appropriate Margin 

Flight systems should provide margin in order to minimize operations constraints. Vehicle thermal, power, and 
communications capabilities should not be designed with operations constraints that result in the necessity for highly 
optimized mission timelines to accomplish normal operations such as rendezvous, proximity operations, and 
docking. Margin in all three of these categories is a significant driver in determining the amount and extent of 
mission- and activity-specific planning and analysis. Significant positive margins in key categories should be 
available in all mission phases. 

At the same time, excessive margin is not operationally desirable and should be avoided. For example, a system 
that provides resource quantities beyond any credible need may use so large a fraction of the allowable mass that 
fewer redundant strings are provided in the design. Expectations on available margin should be bounded by the 
maximum needs for an operational scenario (including off-nominal scenarios). In addition, care should be taken in 
scenarios that involve failure “stacking” (inclusion of multiple separate failure cases in one scenario). Credible 
failure scenarios include those that would allow continued mission execution and those that would initiate the abort 
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or early termination of a mission. Failures after those that drive a mission abort or early termination are generally 
out of scope. 


D. Flexibility 

Flexibility is the ability of the system to accommodate change. This change can be to the mission scenario or to 
the vehicle configuration. When a system is inflexible, even small changes to the mission or vehicle configuration 
may require operational workarounds — additional tasks and responsibilities placed on operations personnel and 
facilities. Flexibility is generally defined by the system's architecture. 


1. Example — Space Shuttle Flexible Payload Capabilities 

The space shuttle provided flexibility through a variety of standardized services. Standardized payload attachment 
systems allowed for a wide variety of payloads and missions. Add-on kits such as the Extended Duration Orbiter 
(EDO) Pallet kit further extended the space shuttle’s capabilities, enabling greater science content and longer 
mission durations. Rather than engineering new solutions for each mission, the Space Shuttle program successfully 
managed an impressive array of separate payloads — from space telescopes and communications satellites to orbital 
laboratories and space station components — using such standardized interfaces. 


2. Recommendations for Achieving Appropriate Flexibility 

Flexible flight systems should be easily reconfigured or updated to account for new conditions and new 
capabilities during flight or between flights. Although this applies to both flight hardware and flight software, the 
impacts of inflexible software are the more acute. Operational experience often identifies necessary changes to 
limits, gains, and other parameters used by flight software. If recompilation of flight software is required to update 
such parameters, then these value updates will be costly and will require months or years to incorporate. 
Operational workarounds will be required for extended periods in order to account for discrepancies between the 
desired and provided values. 

There are reasonable limits to the desired degree of flexibility for an operable system. While some amount of 
flexibility is desired to allow for slight variation in mission profile and vehicle configuration, excessive flexibility 
can result in additional operations challenges. Highly flexible systems may require more training, product 
development, and manual tending than is operationally desirable or affordable. 


E. Situation awareness 

Situation Awareness (SA) is the ability to perceive the state of the vehicle and its operational environment, to 
understand that state, and to project the future state based on that understanding. If systems do not inherently support 
SA, additional operator tools and techniques may be required to provide this insight and understanding. This may 
drive additional operations cost and infrastructure such as facility changes, procedures, training, or even additional 
flight control team staffing. The inability to identify specific anomalies in some scenarios may increase risks to 
mission, crew and vehicle. As a result, some activities or objectives may be disallowed when SA cannot be 
maintained. 


1. Example — Mercury instrumentation 

The very first US orbital flight provided valuable lessons in the importance of appropriate insight into system 
health and status. A single faulty sensor indicated that the landing bag had deployed, potentially compromising the 
heat shield and making atmospheric entry a deadly operation. The operations team scrambled to analyze the 
spacecraft’s condition, and ultimately modified entry procedures to reduce the risk of heat shield loss. Ultimately, it 
was determined that the landing bag and heat shield had been intact and that the deploy sensor itself had failed. 
*Without a way to confirm this while in flight, the conservative approach taken by the crew and flight control team 
was the best course of action. Learning from this and similar experiences, NASA adopted a standard of providing 
“confirming cues” in the Gemini program and beyond, ensuring that secondary cues would be available to confirm 
indications of both nominal and off-nominal conditions. '° 


2. Example — International Space Station Caution and Warning 

The International Space Station provides thousands of separate caution & warning messages to indicate specific 
problems. In the event of significant anomalies - such as loss of an electrical or data bus - dozens of messages may 
be issued to announce each of the multitude of system impacts. Without an automated management system or an 
overarching tool to “synthesize” caution and warming messages into clear indications of failure root cause and 
system impacts, the crew and ground must work through these messages to identify the root cause and critical 
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impacts of that failure. This is enabled through the development and use of detailed procedures and significant 
training to ensure that the operations community is prepared to deal with such cases in real-time. 


3. Recommendations for Achieving Appropriate Situation Awareness 

A balanced approach should be taken in assessing situation awareness. Maintaining situation awareness requires 
the operator to have an overall understanding of the system's state, capabilities and environment. Too much data can 
make this understanding almost as difficult to maintain as can too little data. The best approach to achieving 
balanced situation awareness is the direct involvement of the flight operations community — both crewmembers and 
flight control personnel — in the process of defining system instrumentation and user interfaces. 

Situation awareness should be assured through appropriate telemetry and caution and warning messages which 
allow unambiguous detection and verification of all nominal and off-nominal events. Critical instrumentation, such 
as temperature, mechanism position, and current sensors, should be carefully positioned to directly measure the most 
critical points in the system, reducing or eliminating the need to infer critical information from indirect 
measurements. The instrumentation strategy should provide a means to confirm the indications of one sensor using 
another measured value to mitigate the risk of a single sensor failure Appropriate sensor locations and quantities, as 
well as telemetry display/downlink capabilities should allow the operator to verify automatically generated cues. 
Simple indications should be provided to the operator to identify failures with widespread vehicle impacts. No false 
positive or false negative failure indications should be provided to the operator. 


F. Control 

Control measures the degree and difficulty with which the operator can direct the system's performance during 
operation. This includes not only the availability of all of the control capabilities to appropriately configure the 
system, but also the level of control that the operator must exercise. Use of low level commands — those that control 
individual items at a fine level — may be necessary at times to accomplish specific needs. However, reliance on only 
these low level commands can result in high operator workload because each component must be individually 
configured to accomplish a goal. Higher level commands — those that cause the system to perform multiple steps to 
achieve a predefined configuration — can greatly reduce the level of difficulty in operating the system. Accordingly, 
one effective measure of control is the average count of the number of commands required to implement desired 
courses of action. 

Ineffective commanding capabilities may require the development of additional ground-based software tools to 
support the configuration management, processing, and issuance of commands in an effective manner. Additional 
procedures may be required to support the configuration and processing of commands. Additional training is 
required to enable operators to use these tools and procedures. All of these add to the infrastructure, cost and time 
associated with controlling the spacecraft. 


1. Example — Mercury Manual Control Capabilities 

Project Mercury mangers recognized the technical risks they had undertaken in launching a man into space. Not 
only were they rapidly developing new flight systems, but they also had no knowledge of the human’s ability to 
function in a weightless environment. In response, Mercury was designed to provide both fully automated and 
manual control for most flight phases including ascent . As mentioned above, this approach greatly benefited the 
program by enabling the astronaut to assume control when automated systems malfunctioned, but the cost and 
complexity associated with fully automating systems proved a daunting challenge. 


2, Example — ISS Command Complexity 

As compared to its predecessors, the ISS incorporated a staggering number of separate computers and firmware 
controllers, creating a diverse and distributed network of control loops across the vehicle. The tiered structure of 
hardware control, firmware control, and software control resulted in a complex command architecture. Although 
common Orbital Replaceable Units (ORUs) and firmware controllers were used wherever possible, flight software 
for the ISS’s US segment was developed separately by each of the four major development contractors. Remote 
Power Control Modules (RPCMs) — the basic building block of the electoral power distribution system — were 
integral parts of each contractor’s contribution to the vehicle. Each contractor therefore developed and delivered its 
own separate RPCM control software and implemented the operator command capabilities in a different form. 
Despite the use of common equipment, the user’s command interface appeared overly complex due to these 
variations. Ultimately, the operations community invested significant effort in creating embedded logic within the 
crew displays, forcing a consistent user interface from the crewmember’s viewpoint. 


11 
American Institute of Aeronautics and Astronautics 


In other portions of the power system, commands were unnecessarily complex, including such items as “Hot 
Switch Open Override Inhibit Arm” — the first of two commands sent to allow the operator to subsequently 
command open a switch even when the firmware was set to reject such a command. Such double- and triple- 
negative commands are relatively commonplace and require careful re-naming on operator displays to make user 
interfaces intuitive for the operators. 


3. Recommendations for Achieving Appropriate Control 

Command capabilities should allow the operator to control vehicle functions by setting goals and making 
decisions when queried. Once these goals and decisions have been provided by the crew, the vehicle implements 
them with little or no additional work required on the part of the crew. Routine functions (those that always involve 
the same steps executed in the same order) should be automated. Where appropriate, low-level commands should 
still be provided to allow for effective operations in off-nominal situations. A tell-tale sign of inappropriate 
command strategy is the prevalence of operational procedures that include few decision points but many sequential 
command or switch throw steps. In such cases, automation\of those non-decisional steps should be considered as a 
means to reduce crew workload and system sensitivity to human error. 

The system should operate and respond in a repeatable, predictable manner to each command. The operator 
should have control over the execution of automated capabilities, allowing him/her to proactively prevent or 
reactively terminate the execution of inappropriate actions. The operator should have the capability to correct the 
vehicle configuration when automation either fails to do so or places the vehicle in an undesirable configuration. 

Automation may be applied to address some control needs, but automation may also create other operability 
challenges. In general, automation of well understood operations is achievable and operationally desirable. 
However, automation of actions or responses to scenarios that are not well understood can make operations more 
difficult. Where automation functions must be monitored by operators, halted as required, and replaced by operator 
actions, the automation function may be operationally undesirable. Even in well understood scenarios, the flexibility 
to modify automation through the use of reconfigurable scripts, settings, and other flexibility measures is highly 
recommended. 


II. Challenges in Achieving Operability 


If we understand the problems, why do we not fully address them? Although program managers and subsystem 
designers alike may understand the need for spacecraft flight operability, there remain programmatic challenges in 
implementing operationally desirable features. Recognizing and addressing these challenges early in a development 
program is an essential step in establishing reasonable design and operations solutions. 


A. Development Cost — Now v. Later 

Any spaceflight program faces significant challenges as design, development and test efforts encounter 
problems. Cost increases and schedule slips place increased pressure on program management to reduce program 
content where possible. Priorities shift from optimizing operations phase cost performance to preserving enough 
funding for the delivery and testing of hardware and software. 

During the development phase of Space Station Freedom - the original design that evolved into today's ISS - 
then prime contractor predicted a 50% reduction in operations costs through the implementation of onboard 
monitoring and management functions.'' The Onboard Management Application (OMA) would track resource 
availability and usage and collaborate with other onboard software to ensure that the vehicle automatically adjusted 
in response to resource issues. As the design matured, the top tier of the data processing system was deleted; with it 
the OMA also disappeared. The associated tasks of tracking, predicting, and managing onboard resources was 
relegated to the Mission Control Center, where unique tools and separate console positions were defined to perform 
these functions. The design changes judged necessary to reduce development cost and risk ultimately erased the 
potential for achieving the originally predicted operations costs savings. 

Breaking this cycle — the deferral or deletion of future cost savings enablers in the interest of meeting near term 
goals — is a difficult program challenge and ultimately requires increased development phase funding. 


B. Verification & Validation — Risk and Cost 
Every feature and function of a spacecraft invokes both a risk and a cost associated with verification and 
validation. Program managers are faced with the option of deleting or reducing spacecraft capabilities in order to 
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reduce cost and schedule risks. Where spacecraft capabilities cannot be reduced, reducing the number of unique 
tests and analyses to be completed remains a tantalizing option to address cost and schedule concerns. 

Unfortunately, these risk reduction efforts can negatively impact the flight operations community. When a 
vehicle system is tested and analyzed only for the conditions nominal design reference mission conditions, the 
performance and limits of the vehicle in off-nominal conditions remains unknown. Concerns over possible damage 
to the spacecraft in such unknown conditions increases the need to “protect” the vehicle from such cases and 
ultimately drives the operations community to perform their own analyses, impose more operational constraints, 
develop more contingency procedures, and provide more training to their personnel. The cost of flight operations 
increases to compensate for the losses incurred in reducing development phase costs. 

Early Space Shuttle operations proved difficult as the flight operations team worked to understand the complex 
interaction of the vehicle’s subsystems even as they provided real-time flight control support. Incomplete analysis 
of these interactions during the development phase left the operations team with a significant workload to discover 
and fully understand the complex ways in which the vehicle behaved. The engineering and flight operations 
communities alike invested years of operations in understanding these interactions and formally documenting the 
interactions and responses in procedures and operational flight rules. '* 

The International Space Station “inherited” much of its design from its predecessor — the Space Station Freedom 
Program. The basic vehicle system architecture, as well as its components, were designed for environment in a 
relatively low inclination orbit — 28.5 degrees. As the reborn ISS, however, these systems and components are 
subjected to the extremes of a much higher inclination orbit — a 51.6 degree inclination — to enable inclusion of 
Russian elements and Russian launch vehicles in the overall vehicle assembly. This simple change in mission 
profile, coupled with other major vehicle architecture changes, had significant impacts on overall vehicle 
operability. New extremes in thermal environment included days-long periods of continuous daylight as well as 
shadow patterns cast by the vehicle’s own structure. Time and budget allowed for analysis of some — but not all — 
possible combinations of vehicle attitude and sun exposure, leaving open many questions as to the true 
environmental tolerance of the vehicle. Lack of a thorough understanding of the ISS thermal environment and 
spacecraft component thermal tolerances prior to the operations phase drove the need for significant effort during 
the operations phase to analyze specific cases of unusual attitudes for specific events such as docking and 
undocking. 


C. Lack of Flight Operations Inclusion in Early System Engineering Processes 

The flight operations infrastructure - facilities, people, and processes - are an integral part of the overall system, 
"closing the loop" to control the spacecraft throughout it's mission. As such, that flight operations infrastructure is 
itself a critical control loop that should be carefully designed and measured just as any other spacecraft system or 
program process. However, funding for flight operations specialists in the early phases of a program is typically 
minimal and prioritized much lower than funding for other personnel. This often stems from a basic 
misunderstanding of the role and contribution of the operations community as systems engineers. As a result, true 
cost implications of design solutions are generally not understood or appreciated in time to make informed 
decisions. 

Involvement in definition of operations concepts, requirements, functional allocation of capabilities, and 
implementation trade studies are 
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A comprehensive strategy of flight operations involvement throughout the program lifecycle, as illustrated in 
Figure 7, can benefit human spaceflight programs, both in terms of mission success and program affordability. 


IV. Application to Future Programs 


NASA has applied these lessons learned in supporting the development of the Orion Spacecraft — now the basis 
for the Multipurpose Crew Exploration Vehicle (MPCV). Flight operations team member involvement in defining 
design reference missions, fault management schemes, subsystem architectures, and flight software functionality 
have helped the program improve the operability of its vehicle and enable future cost savings. For example, early 
analysis of the Orion Active Thermal Control System hardware and software design by flight operations personnel 
identified opportunities to significantly improve system robustness through better control schemes and judicious 
addition of flexibility in the control software. These changes were adopted with no net cost to the program. 
Continued collaboration between the spacecraft development and flight operations will allow the MPCV Program to 
continue to identify and address opportunities to improve flight operability. 

Flight operability concerns will become even more critical to the success of human spaceflight endeavors as we 
develop and operate spacecraft that venture farther into space. Deep space flight imposes new operational 
constraints including the inability to execute a timely emergency return as well as time delayed communications and 
reduced communications bandwidth that reduce the ability to apply ground-based real-time support in response to 
real-time events. The next generation of space exploration vehicles must address operability concerns to enable 
their crews to survive and succeed. 

Similarly, the emerging commercial human spaceflight sector must address flight operability concerns in order to 
achieve cost effective operations and realize profitable overall corporate operations. NASA’s lessons learned can be 
a valuable resource in developing cost effective solutions. 


V. Conclusion 


Future human spacecraft development programs can directly benefit from analysis of previous programs’ 
successes and failures in addressing flight operability and its associated costs. Direct involvement of flight 
operations personnel in the development of operations concepts, requirements, and design solutions is a critical step 
in addressing operations phase cost. Formal methods such as use of the Flight Operability Assessment Scale, can 
identify issues and impacts earlier in the development processes. Application of the lessons learned in the first 50 
years of NASA’s human spaceflight campaign can directly benefit new programs by improving spacecraft designs 
and reducing flight operations costs and risk. 
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Find out sesiiiite fe ...Ansteng of wartin “<2 Making Human Spaceflight 
“Rape until you get tf f Practical and Affordable: 


Spacecraft Designs and their 
Degree of Operabilit 


What is flight operability: flight operability measured? tow can this benefit your 


ae AA alae la a? ee Rs ce The Spacecraft Flight Operability Assessment Scale provides a pir q ram: 


1. The degree to which a flight system design enables a balance of 


maximum mission success, minimal risk, and minimum operating cost. formal, structured approach to measuring operability. Flight operability assessment adds another 


Six key factors influence operability. capability to the program manager’s toolset 


Affordability 


Ommonality and consistenc Easy reconfiguration jl Operability issues are linked to e a eae 
C lity and tency Grading scale Maintain ability sustainabitiy 


Simple f : di f Ability to make minor updates : ; ; ale 
ta a i and interfaces \ = (limitsseentrol gains) e Define the range of possible scores and Safety, reliability, performance, 


Ability to upgrade through life cycle their implications to ops and the program ege O b ; | 
e The resulting grades must have meaning Ope fa bi | Ity Fa cto rs Ey but there are other tools D eC fa Ity 
for both the operations community and ° Capture the general factors that drive available to assess these topics. 


A | z= the program management community. ops complexity The operability assessment tool 
vai _ | : e Include description of desired ale aeth 
all operationa ; Performance margin Operational Impact Programmatic impact ae ; a S TO e rogram 
Graceful degradation Robustness Margin Resource margin 1 Excellent operations capabilities Operationally desirable. characteristics In each theme p 8 


Negligible operational challenges that can be handled with no noticeable Mission can be accomplished mM a Nn a ge mM e nt too | S et e 


ei 2| tN: euro ma top time- Environmental tolera nce impactto operations feasibility or cost Minimal operational impacts can 
critical reconfigu ration = ' (temperature, radiation,...) Operational challenges cause noticeable nuisances to the operator, butcan | be handled within existing 


| Vv 
Simplicity | Flexibility 
) Reliability 


Safety 


infrastructure and budget with 
negligible workload impacts. 


V 
Ys it U at j O n Operations are difficult and incur significant one time costs (manpower, Some mission objectives may be Sim plicity Flexi bility e e 1S) e e 
| facilities, products, etc.) to ensure mission success. Some mission objectives atrisk. Operational impacts will 
Contro coma st Cr ldentitying ways in which operations 
requirements, cost allocations, ~ 


a e ess Operations are difficult and incur significant recurring costs (man power, work prioritization, etc. from the 
facilities, products, etc.) to ensure mission success. Some mission objectives 


be handled with little impact to operations feasibility or cost. 


baseline operations plan. 


a = may notbe achieved. / 
o e e 
fs | e r I a Operations are difficult, mission objectives may remain at risk even after Robustness Ma rgin t 
additional investments (manpower, procedures, facilities, etc.) are made. e C Nn | q U eC S Ca Nn al re S S p ro eC mM a re a Ss, ig 


Com ma nd Ca pa bilities e G e n e ra | q U e st | O n S th at Operational challenges reduce mission capability and degree of mission Mission is at risk. 
success by preventing some objectives Operational impacts will exceed 


Telemetry and caution messages Control of automated capabilities : : : peu oe . 
C h ara cte rize O p e rat ions IM p d Cl Operational challenges put mission success at risk. No operational pedantry ah Y Situation 


S locati d titi : ges put missio | 
simple indications fr the operator eee SS ennbecinromentonesen eo pwareness } come operability assessment can also identify 


. . opportunities to make the system developer's 
There are complex relationships between system | =" job easier 


Operationally unsafe or unachievable Not operable. 
pccaptanle Negligible issues 


Nuisance issues Below this point, 


ek anticipated capabilities or 


‘e) ‘e) ege oO ~ 
- budget levels are not 
eC S ! Nn | O = fa I l al Nn r O fa Mm | mM al C ois saoithrieotnal ee a ean 
D D [ } ‘accomplished within normal lo warrant ite basa = 
workload, schedule, improvement a 
cost & risk Significant impact 


limits? 


Program 


Impact Sample Space Shuttle Flight ; 


Operationall 


desirable, Operability Assessment 


Mission can be 


Auyiqixa|s 
ssoulsnqoy 
SSIUDIEMY US 


Net 
Vehicle Design Operability Operational Operational Program | percences | [7_Soneimeee Impact 
Characteristics Impacts Response o> Impact are ce 


| m a ct improvement = - 
Significant impact 


Excellent operations capabilities 


Envi ron ment Life Cycle Can mission be Improvement 


Tolerance Cost accomplished safey?_ >> a na — 7 
& Mission Negligible operational challenges that can be handled with 


Consumable S Gee] eS 
uccess no noticeable impact to operations feasibility or cost 
resource storage EIE Pracedire P P y accomplished 


Capacity Quantity & Operational challenges cause noticeable nuisances to Minimal operational impacts 


Renewable lide tl Complexity the operator, but can be handled with little impact to can be handled within Docking attachment system operability 
resource storage onstraints (risk, time, cost) Operations feasibility or cost. existing infrastructure and 


capacity Reaver budget with negligible assessment for docking operations 


pene rmance Qu a ntity & workload im pacts. Operability Theme Score Description Operational Impact Program Impact 
An a ys | S D ata 1 . . : : a , ' a 2 Multiple nominal and off nominal Coeds) increases epeuetor workload, requiring Some iSite objectives 
Availability es Can mission be Operations are difficult and incur significant one time costs Some mission een procedures 2s well as operational faites ates (woredues, fry beats Scores in simplicity, margin and 
risk, time, COS p pnt. e page zi F pe ke workarounds to disable and release 
Reactive accomplished within normal (manpower, facilities, prod ucts, etc.) to ensure mission obiectives ma be at peak saben eee, undesirable robustness scores reflect the 
opjectives May De at Little margin is available in the APDS Inadequate margin induces risk of loss of mission. Mission is at risk. sign ifica nt ope rational im pa cts of 


Unsafe 


Lod Ayo1jduis 


Flexibilit nae Kine 
System Architecture Y Reconfiguration Analysis Tool workload, schedule, success. Some mission objectives may not be achieved. Hel apc tecnpr eau 
& Connectivity / Needs (cost) cost & risk MSK. need for significant system workarounds evena single failure in the 


= <. s ree 1 ffi I I if i 1 5 P i M i ooks, constraints etc). 
Redundancy Simplicity ave limits? Operations are difficult and incur significant recurring costs Operational impacts will ae <iseiiene join te allow subsystem. 
& Reliability | Pretlight 


mechanism could lead to loss of 
Planning success Some mission objectives may not be achieved. requirements, cost 


(manpower, facilities, products, etc.) to ensure mission change infrastructure Ney 


The semi-automatic docking sequence |Functions enabling flexibility induce additional operator | Mission can be 
allows for much greater system workload within reasonable limits. accomplished. 


Flexibility 


flexibility but also poses issues with 
I 


Hazards Robustness complexity at 
= ANN Proactive (risk, time, cost) Operations are difficult, mission objectives may rem ain at ieee ees f th Sees ee Inability to recover sufficient functionality increases Mission is at risk. 
iti | reconfiguring after the first failure to risk of loss of mission. : F 
Automation Control : fi a risk even after additional investments (manpower, ee cece nee hee Robustness ee eke Scores relatively well in the 
C d Reconfiguration Training Needs ne baseline operations plan Sigglojpeint (am ons tealceren ete ore 
omman proced ures, facilities, etc.) are made. ' eae categories of flexibility, situation 


mechanism can cause loss of mission. 


(time cost) ] ] I | h insight into the health| Required effort to maintain Situational Aw areness Mission can be 
| nterfaces : Can mission be SAT SERRA GEESE peer results in minor workload impacts. accomplished. aWa reness and control, though 


Instrumentation accomplished within tolerable Operational challenges reduce mission capability and Mission ts at risk. Situation available to MCC. Some coordination some limitations capabilities are 


Pi A “ c : c with crew to attain crew only insight ( 
Communication Situation workload, schedule, degree of mission success by preventing some objectives vneteness So ate aed 
Bandwidth Awareness cost & risk 
: : limits? : ; : ae : 
Caution & Warning operational techniques are available to mitigate risk. either the operations 
community or the entire 
Operational challenges increase risk of loss of crew or program. 


vehicle. No operational techniques are available to mitigate 


F| ig ht O pe fa bi | ity fa cto rs Ca Nn CoO nfl ict @ Coed are risk while preserving mission content. 


: -. a... accomplished safely? foyeyevestitolarsl i Wael Att: licMmelm@e late al(evvzclel(s PP yy yd Not operable. 
Simplicity «Flexibility 10 Notoperable, = 


*Operability assessment is performed for a specific reference mission or scenario 


Operational impacts will 


Lack of ground control capability limits | |Command & control interfaces and tasks impact Mission can be 


Operational challenges put mission success at risk. No exceed the capabilities of Control MCC ably to operate the docking vo ran resonate ts eres 


system in off nominal situations. 


Formal definitions and criteria for flight 


operability can benefit the Program throughout 


Significant useful margin Flexibilityis seamlessly provided _No further action is required SA is properly maintained in all scenarios Cc 
is available in most or all without requiring additional operator wi id 
es. action. 


@ @ @ Functions, interfaces ai nis yr ‘command interfaces are a) e 
lasks require lowest prac of the operator after this ith no additional operator action cient and do not contribute 
operator workload and cast le reconfiguration required. significantly to operator 
fio] [oe infrastructure. workload. 
Minor complexity may cause Someusefulmarginis Functions enabling flexibility induce System functionality is M Si ‘command & control interfaces e 
nuisances but does not available in most cases. nuisances but do not impact preserved, but non-critical noticeable but do not add to operator include some nuisances that do 
impact operator workload. operator workload. activities may be temporarily workload. not impact workload. 
hi 
inor complexity increas 


impacted by the recover y 
process. 
es Slight useful marginis Functions enabling flexibility induce ste nality is Required effortto maintain Situational Command & control interfaces 
it available in most cases. additional operator workload within preserved, but some Awareness results in minor workload —_ and tasks impact workload but 
reasonable limits. activities may be interrupted impacts. remain in reasonable limits. 
steps 


operator workload, but 
® oO oO ia) @ oO @ orkload remains in 
reasonable limits. 
n. 
‘complexity increases Lack of margin drives Additional tools and infrastructure itional operator actionis Additional tools must be developedto — Additional infrastructure must 
operator workload ani additional ope! must be developed to support required to establish normal achieve the necessary level of Situational be developed to support 
requires additional tools to infra: flexibility (data and software function after a failure. Awareness. command and control p rog ra Mm 3 a 
support the operator. capal ). reconfiguration, etc.) capabilities. Op F | Fl B Te | & 
complexity increases ack o' in driv procedures, ools and procedures are Ss u nctio n a Ow u 1 
operator workload, requiring additional struc training, etc.) must be developed to required to achieve necessal ‘s J 
additional tools and aci contro Concept Block Diagrams 


and processes are required to ensure 
accommodate the lack of inherent roper response to possible achieve the necessary level of Situational 
system flexibility. failures. Awareness. 


id B 
@ @ @ echniques (procedures, —_capal sis an 
constraints, etc.). S) 
es i ure Infrastructure and procedural Manual pre-configuration Even with additional tools and Extra tools and techniques are 
infrastruc ‘osts, but risk and proce: cannot workarounds are required, buteven —_ alone cannot complete! techniques, some non-critical conditions required to achieve necessary 
io some Nn objectives u iti tiskto these do not mitigate all risk to some mitigate risks, some mission cannot be effectively identified. control, but workload impacts 
remains. mi: ; mission objectives. objectives remain at risk. may impede completion of 
some mission o} bjectives. 
complexity prevents Inadequate margin acl 
co fe prevents ac lishment es 


of necessary flexibility will Inability to recover su i nstraints Insufficient control capability is 
f some mission f ort execution 


ives Excessive procedural workarounds fe) be =A se ane re- A Ta che mee roc Req ui re m e nts 
Phase phe 
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° ° : Operability assessments 
Application Operations concept clear guidance for design E : 


ac nts a is! r 
bjecti S of so ission 
Oo O Oo e Oo objectives. 
Complexity drives operational Inadequate margin Lack of necessary flexibilityinduces Inability to recover sufficient Lack of suitable SA increases risk of loss_ Insufficient control capability is - s 
hr induces risk of loss of additional risk of loss of mission. _ functionality increases risk of of mission due to potential operator error. provided to respond to . o,e . a p p | | e d to p ro p O S e d d e S | gs Nn 
mission. loss of mission. anomalies that risk loss 0 definition includes factors im lementation 
issi p 
Complexity drives operational Inadequate margin Lack of necessary flexibilityinduces Inability to recover sufficient Lack of suitable SA increases risk of loss Insufficient cont ability is a & C h a n ge S a n d U pg fa d e S 
constraints that increase risk induces risk of loss of additional risk of loss of crewor _ functionality increases risk of of crew or vehicle due to potential rovided to jond to t h at | mM p a ct fl | gs ht 
vehicle. Operator e! ant 
d [ 


in loss o unction t i ations, placing —_ provided to support 
Ib} 


Operability criteria provide 


objectives. completion o ission ission objectives at risk. of some mission objectives. 
obje 


of loss of ehicle. crew/vehicle. loss of cre\ vehicle. 


cause te aperaoriotake " ssofcreuvehice) include operability criteria ensure requirements 


crew/vehicle. 5 
Cc I It Inad Inflexibilit fi d Cc I f ti S t q t ale 
" So a ee eee eee ee ae operations ystem requirements Formal operability assessments 
mission, vehicle and crew. mission. failure causes loss of crew or art t t imp: 0! 
icle. indi 
compliance 


rew/vehicle survival. Will cause criti 
impacts to nominal operations. 


The Spacecraft Flight Operability Assessment Scale is a product of the Mission Operations Directorate at NASA’s Johnson Space Center. oi » 


Point of Contact: Alan Crocker, alan.r.crocker@nasa.gov 


